DEV Community

I Built an AI That Fixes Terraform Drift Automatically

Sudarshan Thakur — Sun, 23 Aug 2026 17:37:22 +0000

I Built an AI That Fixes Terraform Drift Automatically

If you've worked with Terraform long enough, you know the feeling. You run terraform plan and suddenly there are 12 unexpected changes. Someone tweaked an instance type in the console. A security group rule got added manually. A tag got removed. Your infrastructure drifted — and now you have to figure out what changed, why, and how to bring it back in line.

Detecting drift is one thing. Actually fixing it is where engineers waste hours.

That's what I built tfdrift remediate to solve.

What is tfdrift?

tfdrift (https://github.com/sudarshan8417/tfdrift) is an open-source CLI for continuous Terraform and OpenTofu drift detection. It runs terraform plan across all your workspaces, classifies drift by severity (critical/high/medium/low), and sends alerts to Slack, Teams, or OpsGenie.

Version 0.5.3 ships a new command — tfdrift remediate — that takes detected drift and uses AI to generate a ready-to-review .tf remediation file.

The Problem With Fixing Drift Manually

When drift is detected, the typical workflow is:

Look at the terraform plan output
Figure out which attributes changed
Manually update your .tf files to match desired state
Run terraform apply

For 1-2 resources this is fine. For 10+ resources across multiple workspaces, it becomes a slow, error-prone process — especially when you're dealing with complex resource types like aws_security_group, aws_iam_role_policy, or azurerm_virtual_network.

How tfdrift remediate Works

The flow is simple:

tfdrift remediate --path ./infra

Scans all your Terraform workspaces for drift
Lists every drifted resource with severity and number of changed attributes
Asks whether you want to fix everything or just specific resources
Calls AI (Claude or GPT-4o) with full drift context
Writes a drift-remediation.tf file you can review and apply

Here's what the interactive prompt looks like:

Found 3 drifted resource(s):

aws_instance.web 🔴 high — 2 attribute change(s)
aws_s3_bucket.logs 🟡 medium — 1 attribute change(s)
aws_security_group.app 🔴 high — 3 attribute change(s)

What would you like to remediate?
A — All resources
S — Select specific resources (comma-separated numbers)
Q — Quit

Choice [A]:

Choose S and enter 1,3 to fix only the high-severity ones. Or hit A to generate remediation for everything.

The AI Output

The AI receives the full drift context — resource type, action needed, and every attribute that changed with its desired vs actual value. It outputs valid HCL with inline comments explaining each correction:

drift-remediation.tf

Generated by tfdrift remediate

Drift detected: 3 resource(s) across 1 workspace(s)

aws_instance.web — instance_type drifted from t3.medium to t3.large

aws_security_group.app — ingress rules modified out-of-band

Restores instance type to desired state (was changed from t3.medium to t3.large in console)

resource "aws_instance" "web" {
instance_type = "t3.medium" # corrected: actual was t3.large
# ... other attributes unchanged
}

Removes manually added ingress rules

resource "aws_security_group" "app" {
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
}
# ... other attributes unchanged
}

Review it, make any adjustments, then apply:

terraform apply drift-remediation.tf

Dual AI Provider Support

tfdrift remediate auto-detects which AI provider to use based on your environment variables:

Set ANTHROPIC_API_KEY → uses Claude (preferred)
Set OPENAI_API_KEY → uses GPT-4o (fallback)

You can also force a specific provider:

tfdrift remediate --provider openai --path ./infra

Getting Started

pip install 'tfdrift[ai]'

with Claude

export ANTHROPIC_API_KEY=sk-ant-...
tfdrift remediate --path ./infra

with OpenAI

export OPENAI_API_KEY=sk-...
tfdrift remediate --path ./infra

Optional flags:

Fix everything without the interactive prompt

tfdrift remediate --all

Custom output file

tfdrift remediate --output my-fixes.tf

Use OpenTofu instead of Terraform

tfdrift remediate --binary tofu

Why Not Just Run terraform apply?

tfdrift remediate is not the same as tfdrift scan --auto-fix (which actually runs terraform apply). The AI remediation command generates a file for you to review first — the AI explains what it's correcting and why, you verify it looks right, then you apply.

This matters in production. You want a human reviewing the fix before it touches infrastructure.

What's Next

Support for multi-workspace remediation plans in a single file
Severity filtering (--min-severity high to only remediate critical and high drift)
GitHub PR generation — auto-open a PR with the remediation file

tfdrift is open source (Apache 2.0). If you're using it or have feedback, open an issue or drop a star on GitHub (https://github.com/sudarshan8417/tfdrift).

Styled Unicode Breaks Character Counters

Eugen — Sun, 23 Aug 2026 17:36:52 +0000

A 76-character bio, styled once, no longer has one useful length.

const s = "𝐚𝐞𝐬𝐭𝐡𝐞𝐭𝐢𝐜";
[...s].length                          // 9   code points (and 9 graphemes here)
s.length                               // 18  UTF-16 units — what String.length counts
new TextEncoder().encode(s).length     // 36  UTF-8 bytes  — what storage counts

Three defensible answers, factor of four on one word. I found this while auditing a counter beside field limits I do not own. The counter reported code points; the destination's unit was unknown. That is already enough to make a green "safe" verdict dishonest.

Styled letters from the Mathematical Alphanumeric Symbols block live in the Supplementary Plane: 1 code point = 2 UTF-16 units = 4 UTF-8 bytes. If you display one number next to a limit documented only as "characters", you are making a claim about a unit the destination never published.

What a real bio line does

Same 76-code-point line, four styles. Measured, not recalled:

style	code points	UTF-16	UTF-8 bytes
plain	76	76	76
Bold `𝐀`	76	134	250
Script `𝒜`	76	117	225
Small Caps `ᴀ`	76	76	155

A code-point counter calls Bold "76". The same text occupies 134 UTF-16 units or 250 UTF-8 bytes. If the destination budgets one of those units, a verdict based on another is meaningless. Documentation that says only "characters" does not resolve it.

Honest UI: three states, not a green number

Measure all three. If the destination explicitly publishes a byte limit, enforce it. If it publishes a character limit without naming the unit, keep bytes visible but do not compare them to the same number: byte and character budgets are not interchangeable.

const measure = (s) => ({
  codePoints: [...s].length,
  utf16: s.length,
  bytes: new TextEncoder().encode(s).length,
});

// ok    — fits by code points and UTF-16; bytes are reported separately
// risk  — fits by code points, not by UTF-16: the field decides, and it did not say
// over  — too long even by the most generous count
const state = (m, limit) =>
  m.codePoints > limit ? "over" : m.utf16 > limit ? "risk" : "ok";

risk is the honest answer when the platform has not told you the unit. The only way to name the unit is to paste a known-length styled string into the live field and see where it cuts. Until then, do not draw a green bar.

The next failure is truncation, not the count

.slice(), .substring(), and [0..n] on a JavaScript string cut at UTF-16 boundaries. An odd index inside a Supplementary character keeps half a surrogate pair. Many encoders and renderers replace that lone surrogate with U+FFFD:

"𝐚𝐞𝐬𝐭𝐡𝐞𝐭𝐢𝐜".slice(0, 7)   // "𝐚𝐞𝐬\uD835"  → renders 𝐚𝐞𝐬�

Truncate on code points — and on grapheme clusters if you allow combining marks (a̶ is two code points):

const cutCodePoints = (s, n) => [...s].slice(0, n).join("");
const cutGraphemes = (s, n) =>
  [...new Intl.Segmenter(undefined, { granularity: "grapheme" }).segment(s)]
    .slice(0, n)
    .map((g) => g.segment)
    .join("");

Where the rest of the measurements live

I did not want a second guessed number in the UI, so I ran this against a shipping 22-style catalog rather than a handful of examples. Length units, the NFKC rule that flattens 17 of those 22 styles, coverage holes per family, and how /\d/ in JavaScript disagrees with Python on 𝟐𝟎𝟐𝟔 are written up with the reproducing code in Unicode text in fields you do not own (CC0).

Checklist I actually use:

[ ] Count in all three units; never show one number as if it were the limit
[ ] Truncate on code points or graphemes, never on UTF-16 indices
[ ] Normalise before validating; know whether your storage path normalises
[ ] Test rendering on a device you did not compose the text on
[ ] Disclose coverage holes instead of silently substituting another letter

The catalog those numbers were measured on is the type-style-copy tool at fontius.app. The skill is the document; the tool is just where the 22 families live.

Research disclosure: The catalog measurements come from focused local tests against the 22 shipped styles. I did not establish which unit any named third-party platform uses; that requires testing the field itself.

AI-assistance disclosure: AI tools assisted with research navigation, code verification, and drafting. I reviewed the evidence and take responsibility for the claims and conclusions.

Everything, All at Once

Sanjeev Sharma — Sun, 23 Aug 2026 17:28:58 +0000

By the end of this post, you'll learn how I work faster with coding agents and run more work in parallel.

Development looks very different form a year ago.

I can't remember the last time I wrote a line of code myself. Over time, I've built workflows and systems that let me trust agents with much more of the development process.

I was also fortunate to start working on a large greenfield project right when agentic coding started picking up. For the project, I intentionally chose popular, battle-tested tools like shadcn, Tailwind, and React Query. They're well documented and widely used, so agents already understand most of the patterns around them.

The project had six frontend developers working on it at its peak — the largest frontend team I've worked with on a single project. While the team was building features, I was working on our custom coding agent.

After multiple iterations, it can now gather requirements from Jira, Slack threads or Figma, implement a feature, write tests, resolve PR comments, fix CI issues and ship to staging for review — all without a human in the loop.

And we've started shipping a lot more code because of it. It has reached a point where one of the most common questions in my team is — "How can I work on multiple things in parallel?"

But before you start running five agents at once, you need a good workflow for running one.

Here's how I approach both.

Working on a Single Feature, But Better

Let's say you're working on building a login feature end to end.

You don't jump into dev right away, you'd probably ask your agent to write a spec for you. Most devs would run an agent and ask it to implement the spec. The agent would most likely finish it but it takes a lot more time and you only see the result in the end.

Here's how I'd do it.

I will ask my agent to write a technical spec. This will involve exploring the codebase and coming up with contracts. This is where I would agree on the seams and review the contracts between different modules — UI, Redux/RQ, APIs and DB schema.
Next, I would ask my agent to break down the spec in phases, where each phase is verifiable by me or the agent itself. Also, I'd ask my agent to tag the phases based on whether they can be worked on in parallel.
I'd ask the agent to implement the plan and also let it run subagents for parallel work.

Note: I store the spec and phased-plan somewhere. Usually, I store it in a .tmp directory in my codebase. This is important if I wanna run multiple agent sessions for a large piece of work. I've added .tmp to .gitignore so it only lives on my system and isn't tracked.

I have skills for all these steps, so I don't hand hold my agent every time.

This workflow not only gives me more time back but also gives me the confidence that the agent has built what we both initially agreed upon.

I've been building flowflight — a focus timer for coding with music or white noise. Give it a try if that sounds like your thing. ❤️

Working on Multiple Features, At Once

This is the next phase.

You've figured out how to build one feature well. Now it's time to run parallel agents for different features at the same time.

But one codebase can only have a single branch checked out. So how do you work on different features?

A few months ago, when I ran into this exact problem, I made a copy of my codebase and opened two editors. It became messy pretty quickly, and I thought there had to be a better way.

That's when I found Git Worktrees!

Worktrees have been around since 2015, but they've got more relevant recently when the world started moving faster with agentic coding.

Let's say you're working on the same login feature and you've got an urgent hotfix to ship. Traditionally, you'd stash your work, check out a different branch, deploy your fix, come back to your branch and pop your stash back. This is okay but it can be better — faster!

Here's how I'd do it:

Create a worktree. (without stashing my work)

git worktree add ../hotfix-tree -b hotfix main

This will instantly create a directory beside my current working directory and create a new branch hotfix based on main. I can open it in another editor, fix the issue, and push it.

code ../hotfix-tree
git add .
git commit -m "fix: add validation for email"
git push

Once I'm done, I can remove the worktree from my original directory.

git worktree remove ../hotfix-tree

That's it!

And this isn't limited to bug fixes.

You can create multiple worktrees and run an agent inside each one, with every agent working idependently on a different feature.

It's basically multiple branches, checked out and worked on at the same time.

A few things to keep in mind:

Each worktree will have its own copy of dependencies, so you may run into disk space issues.
Git prevents you from checking out the same branch in multiple worktrees. This is to prevent data corruption.

I hope this post makes your workflow better and you ship at lot more code faster. Happy building! ✌️

I Built an Open-Source AWS Cloud Security tool for solo devs & founders !

Kavee — Sun, 23 Aug 2026 17:27:53 +0000

If you're a solo dev running your own AWS account with no security team, you've probably had this thought: is my IAM setup actually fine, or did I just get lucky? Plexavo exists to answer that for people in that exact position, not for teams that already have Wiz.

What it does

pip install plexavo plexavo scan --profile prod --report-html

Scans IAM, S3, EC2, and networking for misconfigurations and privilege escalation paths. Returns a 0-100 score and a plain-English report: what's wrong, what an attacker does with it, the exact command to fix it. Runs on your own local credentials zero telemetry, nothing leaves your machine.

A RESULT OF A REAL FINDING - https://plexavo.com/sample-report

Why it's deterministic, not AI

Detection is pure Python/boto3 no model decides what counts as a finding. A security scanner that hallucinates a finding doesn't just get something wrong, it gets uninstalled and never trusted again. There's an optional AI layer (your own API key) that rewrites findings into plainer language, but it never decides what's flagged, and it's fully opt-in.

Try it, break it, tell me

Run it against your own account I'd rather hear what it flagged (or where it broke) than get a star.
Contribute issues and PRs are genuinely welcome, it's early (v0.1.2) and there's a lot still to build.
Review the code deterministic checks mean you can actually audit what it's doing, not just trust it.
Contact me directly if you want to talk about it happy to answer anything.

Repo: - https://github.com/plexavo/Plexavo

Debugging Is the Killer App for Free Model Tokens — Here's the Workflow

Dakota Liu — Sun, 23 Aug 2026 17:21:08 +0000

Most developers treat free model tokens as a code generation budget. They ask for snippets, refactors, and explanations, then wonder why the tokens disappear without making their codebase measurably better. I think the highest-leverage use is debugging. A model that reads your error logs and produces a ranked list of hypotheses can save you more time than any code snippet it generates, because debugging is where developers lose hours to tasks that are pattern-matching, not reasoning. This article shows a reproducible workflow for turning free model tokens into a debugging assistant, using an OpenAI-compatible endpoint and a few lines of Python.

The argument isn't that code generation is useless. It's that code generation produces artifacts you still have to review, test, and integrate, while debugging produces a diagnosis you can immediately act on. The marginal value of a correct diagnosis is higher than the marginal value of a correct snippet, because the diagnosis unblocks you and the snippet only starts your work.

Why Debugging Is the Right Job for Free Model Tokens

Debugging is fundamentally a pattern-matching exercise. You have a stack trace, a log message, and a set of known failure modes. The model has seen thousands of similar errors during training, so it can quickly map your symptoms to likely causes. That's a different skill from writing a feature from scratch, where the model has to invent something new.

Debugging also benefits from the model's ability to hold context. You can feed it the error, the surrounding code, and your recent changes, and it will connect dots that you might miss after hours of staring at the same screen. The feedback loop is fast: you try a hypothesis, and if it's wrong, you ask a follow-up question with more context.

Finally, debugging is expensive. Every hour you spend chasing a bug is an hour you're not shipping features. If a model can cut that time in half, it's worth more than a hundred generated functions that you still have to test.

The Workflow: From Error Log to Ranked Hypotheses

The workflow has five steps, and only the last one spends tokens.

Collect the logs. Pull the last hour of logs from your application, or the log file from the failed run.
Extract the error block. Find the most recent exception or error. Include a few lines of context before the stack trace, and the full trace itself.
Build a prompt. The prompt should contain the error block, a hint about your project structure, and a request for ranked hypotheses.
Call the model. Use an OpenAI-compatible endpoint. The script below does this.
Verify the top hypothesis. Try the fix. If it doesn't work, ask the model a follow-up with the new error message.

The key is to give the model enough context. A bare stack trace often isn't enough. Add the function names, the values of key variables, and any recent changes you made.

A Reproducible Script

Here's a minimal Python script that implements this workflow. It reads a log file, extracts the last error block, and calls a model to get ranked hypotheses.

#!/usr/bin/env python3
"""debug_assistant.py — use a free model to analyze error logs."""
import json, os, sys, urllib.request
from pathlib import Path

def extract_error_block(log_text: str, max_lines: int = 50) -> str:
    lines = log_text.splitlines()
    for i in range(len(lines) - 1, -1, -1):
        if "Traceback" in lines[i] or "ERROR" in lines[i]:
            return "\n".join(lines[max(0, i - 5):i + max_lines])
    return log_text[-2000:]

def call_model(prompt: str) -> str:
    payload = {
        "model": os.environ["DEBUG_MODEL"],
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.2,
    }
    req = urllib.request.Request(
        os.environ["DEBUG_BASE_URL"] + "/chat/completions",
        data=json.dumps(payload).encode(),
        headers={
            "Authorization": "Bearer " + os.environ["DEBUG_API_KEY"],
            "Content-Type": "application/json",
        },
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        return json.load(resp)["choices"][0]["message"]["content"]

def main() -> int:
    log_path = Path(sys.argv[1] if len(sys.argv) > 1 else "error.log")
    log_text = log_path.read_text()
    error_block = extract_error_block(log_text)

    prompt = f"""You are a debugging assistant. Analyze the following error log from a Python application and provide:
1. The most likely root cause(s), ranked by probability.
2. A specific fix for each, with code if applicable.
3. Any additional logging or checks that would confirm the diagnosis.

Error log:
{error_block}

Project context (from environment):
{os.environ.get("DEBUG_PROJECT_CONTEXT", "No additional context provided.")}

Be concise. Output as a numbered list."""
    print(call_model(prompt))
    return 0

if __name__ == "__main__":
    sys.exit(main())

To use it:

export DEBUG_BASE_URL="https://your-endpoint.example.com/v1"
export DEBUG_API_KEY="your-key"
export DEBUG_MODEL="your-model"
export DEBUG_PROJECT_CONTEXT="FastAPI app with PostgreSQL and Redis"
python debug_assistant.py app.log

The script is intentionally simple. It doesn't handle multi-file logs or interactive follow-ups, but it's enough to show the pattern.

Why a Free Server Makes This Practical

Debugging is interactive. You'll often make multiple calls per session, refining the prompt as you learn more. That's where cost becomes a barrier. If you're paying per call, you might hesitate to ask a follow-up question. A free server removes that hesitation.

MonkeyCode is an open-source project that provides free model access and a free server option, with 10 million free tokens in the current offering. That's enough for thousands of debugging sessions. The endpoint is OpenAI-compatible, so the script above works without modification.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I'm repeating those availability claims as provided by the project, not as verified by my own stress testing. Quotas, uptime, and terms can change, so check the current details before you wire this into a production pipeline. The script itself is endpoint-agnostic; if you switch providers, the only change is the base URL and key.

Limitations and Who Should Skip This

This workflow has real limits. The model can hallucinate plausible-sounding causes that have nothing to do with your bug. Always verify before changing code. It also can't see your entire system; it only knows what you put in the prompt. If you omit a key detail, the diagnosis will be wrong.

Security matters. If your logs contain customer data or secrets, don't send them to a third-party model. Run a local model or sanitize the logs first.

Skip this workflow if your project has no logging, if you're working in a tightly coupled legacy system where context is too large to summarize, or if you're debugging a race condition that requires reproducing the exact timing. Models are better at logical errors than concurrency issues.

The Position

Free model tokens are a scarce resource, and scarcity demands prioritization. Code generation is a nice-to-have; debugging is a must-have. Every hour you save on debugging is an hour you can spend on the work that actually matters. So next time you hit a mysterious error, don't just copy the stack trace into a search engine. Feed it to a free model and let it rank the hypotheses. The first time it points you to a root cause you'd have missed, you'll be convinced.

VeloxDB : database admin tool for Linux

abeni16 — Sun, 23 Aug 2026 17:20:55 +0000

VeloxDB is an open-source database management tool built with Rust and Tauri 2, available for Linux as .deb and .AppImage packages (x64 and ARM64).

It supports 6 database engines — PostgreSQL, MySQL, MongoDB, Redis, SQLite, and DuckDB — plus wire-compatible cloud services like Supabase, PlanetScale, and Atlas. Connections work by pasting any standard URI (postgresql://, mysql://, redis://, mongodb(+srv)://, sqlite://), with engine, host, port, and credentials auto-detected.

Other features: schema-aware SQL autocomplete, a visual ER diagram designer (drag-and-drop, migration generation, export to SQL/PNG/PDF), SSH tunneling, SSL/TLS support, and an inferred schema view for MongoDB collections and Redis keys.

Since it's built with Tauri instead of Electron, the download is 17–30MB and memory usage stays around ~50MB. No telemetry, everything runs locally.

MIT licensed. Site: visit here

Dynamic Programming: The Matrix of Patterns

Timevolt — Sun, 23 Aug 2026 17:20:43 +0000

The Quest Begins (The "Why")

I still remember the first time I saw a dynamic programming question pop up on a whiteboard during an interview. The problem was simple: given an array of integers, find the contiguous subarray with the largest sum. My brain went straight to the brute‑force idea—check every possible start and end, keep the best sum. Two nested loops, O(n²) time, and a sinking feeling that I was about to waste twenty minutes of the interviewer’s patience. I coded it, ran a few test cases, and watched the runtime blow up on larger inputs. It felt like trying to defeat a boss by swinging a sword at its feet over and over—ineffective and exhausting.

I knew there had to be a smarter way, but the explanations I found online jumped straight into the code without ever telling me why the trick works. I wanted to understand the underlying logic, not just memorize a pattern. That curiosity turned into a mini‑quest: uncover the secret behind linear‑time DP solutions and share it with anyone who’s ever stared at a nested loop and wondered, “There’s gotta be a better way.”

The Revelation (The Insight)

The breakthrough came when I stopped thinking about “subarrays” and started thinking about decisions. For each position i in the array, there are only two meaningful choices for the best subarray that ends exactly at i:

Start a new subarray at i (the sum is just nums[i]).
Extend the best subarray that ended at *i‑1* by adding nums[i] to it.

If we already know the maximum sum of a subarray that ends at i‑1, we can compute the answer for i in constant time. That’s the heart of optimal substructure: the solution to a problem depends only on the solution to a smaller, overlapping subproblem. And because we reuse the same computation for every index, we avoid the exponential blow‑up of naive recursion—classic overlapping subproblems.

Mathematically, we define dp[i] as the maximum sum of a subarray that ends at index i. The recurrence is:

dp[i] = max(nums[i], dp[i-1] + nums[i])

Why does this work?

If nums[i] alone is bigger than extending the previous subarray, then any optimal subarray ending at i must start at i (otherwise we’d be dragging a negative or useless prefix).
Otherwise, the best we can do is to take the best ending at i‑1 and tack on nums[i]; dropping the prefix would only make the sum smaller.

Notice we never need to look beyond the immediate predecessor. That means we can keep just one variable instead of an entire array, turning the space complexity from O(n) to O(1). Each element is processed once, giving us O(n) time—linear, clean, and ready for interview whiteboards.

Wielding the Power (Code & Examples)

The Struggle: Brute Force

def max_subarray_bruteforce(nums):
    best = float('-inf')
    for i in range(len(nums)):
        current = 0
        for j in range(i, len(nums)):
            current += nums[j]
            if current > best:
                best = current
    return best

Two loops, O(n²) time. It works, but it feels like hammering a nail with a screwdriver—technically possible, painfully slow.

The Victory: Kadane’s DP

def max_subarray(nums):
    # Handles the all‑negative case by starting with the first element
    best = current = nums[0]
    for x in nums[1:]:
        # Either start fresh at x, or extend the previous segment
        current = max(x, current + x)
        best = max(best, current)
    return best

That’s it. Four lines inside the loop, constant extra space, linear time.

Common Traps

Forgetting the all‑negative case – If you initialise best = 0, the algorithm would incorrectly return 0 for an array like [-3, -2, -7]. Starting with the first element fixes that.
Mis‑placing the reset – Some try to reset current to 0 when it drops below zero. That works only when you know the answer isn’t negative; safer to stick to the recurrence current = max(x, current + x).

A Second Interview Flavor: Best Time to Buy and Sell Stock

The same DP pattern appears in LeetCode 121: max profit from one buy‑sell transaction. Think of price[i] as the “cost” of holding a stock up to day i. The profit if we sell today is price[i] - min_price_so_far. We keep the smallest price seen so far (the “best buy”) and compute the best sell profit in one pass.

def max_profit(prices):
    min_price = float('inf')
    max_profit = 0
    for p in prices:
        min_price = min(min_price, p)          # best buy up to today
        max_profit = max(max_profit, p - min_price) # best sell today
    return max_profit

Again, O(n) time, O(1) space, and the same “look only at the previous step” intuition.

Why This New Power Matters

Once you see the DP lens—optimal substructure + overlapping subproblems—a whole family of problems clicks into place:

Maximum sum subarray with at least one element (the classic we just solved).
Longest alternating subarray (track two states: expecting up or down).
Minimum path sum in a grid (each cell depends only on top or left neighbor).
String edit distance (though that’s O(n*m), the same principle).

The beauty is that you stop memorising “templates” and start deriving them. When you encounter a new problem, ask: What decision am I making at position *i? What’s the smallest piece of information I need from the past to make that decision optimally?* If the answer is a constant‑sized summary (like a max, a min, or a bool), you’ve got a linear‑time DP waiting to be written.

This shift turns interview anxiety into excitement. Instead of dreading the nested‑loop trap, you’ll spot the recurrence, write the clean loop, and watch the interviewer’s eyes light up.

Your Turn

Grab a piece of paper (or your favorite IDE) and try this:

Given an array nums, find the maximum sum of a subarray that must contain at least one negative number. If no such subarray exists, return the maximum element.

Hint: you’ll need to keep two DP states—one for the best sum ending at i that has seen a negative, and one for the best sum that hasn’t.

Drop your solution in the comments, share a “aha!” moment, or just tell me which DP pattern made you feel like you finally leveled up. Let’s keep the quest going—because every linear‑time loop you write is another boss defeated. Happy coding!

The CSS bug that taught me JS-injected styles always win

Nogan's Development — Sun, 23 Aug 2026 17:20:27 +0000

I spent way longer than I'd like to admit chasing a dark mode bug that made zero sense on paper.

I'm building WidgetForge, a drop-in AI chat widget you can paste into any site — static HTML or Next.js, pick a theme, done. Four themes, one shared JS core. Nothing exotic.

Except one small piece of it kept breaking dark mode, and I couldn't figure out why.

The setup

Every message in the chat has little icons — a voice note badge, status icons, that kind of thing. I wanted those to invert properly in dark mode, so I wrote the obvious CSS:

@media (prefers-color-scheme: dark) {
  .voice-message-icon {
    filter: invert(1) brightness(2);
  }
}

Dropped it in the theme's style.css. Tested it. Worked fine in isolation.

Then I wired it into the actual widget and dark mode just... didn't apply. Same class name, same media query, same browser. No console errors. No typos I could find. It was the kind of bug where everything looks correct, which is the most annoying kind.

Where it actually was

Here's the thing I didn't clock at first: this specific icon isn't rendered from the static HTML at all. It's built at runtime, in JS, when a voice message gets added to the chat:

(function injectVoiceMessageStyles() {
  if (document.getElementById("voice-message-badge-styles")) {
    return;
  }

  const style = document.createElement("style");
  style.id = "voice-message-badge-styles";

  style.textContent = `
    .voice-message-icon {
      width: 16px;
      height: 16px;
      object-fit: contain;
      flex-shrink: 0;
    }
  `;

  document.head.appendChild(style);
})();

If your styles are partly generated by JS at runtime — dynamically injected <style> tags, CSS-in-JS, whatever — treat that as its own independent stylesheet. It doesn't matter how well-organized your "real" CSS file is if a script is appending a competing block after it loads. External stylesheets are static and load once; JS-injected blocks can show up whenever, and they'll happily override anything sitting above them in the cascade.

Once I knew to look for this pattern, I found two more spots in the same codebase doing the same thing — dynamically created UI elements with their own injected styles that had quietly drifted out of sync with the main theme file. Same fix each time: move the state-dependent rules into the block that's actually authoritative for that element.

Small bug, but it changed how I think about where styling logic should live once JS starts generating markup at runtime.

WidgetForge is a self-hosted AI chat widget — static HTML or Next.js, four themes, no database, no build step.

Live demo
Get the full template

Making AI Coding Agents More Efficient: My Local Toolkit

Ammar Najjar — Sun, 23 Aug 2026 17:17:43 +0000

Giving AI coding agents more tools doesn’t necessarily make them more efficient.

After using OpenCode and Claude Code heavily, I started focusing less on adding capabilities and more on controlling the information flowing into the agent.

That means:

searching before reading entire files
choosing between text, structural, and semantic search
reducing noisy command output
keeping sessions focused
defining explicit stopping rules

I’ve documented the toolkit I currently use, including Headroom, RTK, Caveman, Serena, rg, fd, ast-grep, jq, yq, and others, along with how I define their responsibilities in AGENTS.md.

The principle behind all of it is simple:

Give the agent the smallest amount of information necessary to make the next correct decision.

Full post:
https://ammar-najjar.com/blog/local-ai-coding-toolkit/

I measured 20 "free dofollow" backlink sites. One of them was real.

Linkhiver developer — Sun, 23 Aug 2026 17:15:32 +0000

I run a small link-in-bio SaaS. Like every other founder with a new domain and no authority, I went looking for the "100 free dofollow backlink sites" lists.

So I wrote a script and checked them. Twenty platforms, one at a time, on real published pages.

Exactly one of them gives a free user a followed, indexable link.

Not because the lists lie about rel. They're often right about rel. They're just measuring the wrong thing — and the way they're wrong is interesting enough to be worth writing down, because the same four failure modes explain almost every result.

The script

Nothing clever. Fetch a real published listing page, pull the robots meta, the canonical, and the rel of every outbound anchor:

#!/bin/bash
# gate.sh <url>
U="$1"
UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 \
(KHTML, like Gecko) Chrome/126.0 Safari/537.36"
curl -sSL -A "$UA" -o /tmp/body.html --max-time 25 "$U"

grep -io '<meta[^>]*name=["'"'"']robots["'"'"'][^>]*>' /tmp/body.html | head -3
grep -io '<link[^>]*rel=["'"'"']canonical["'"'"'][^>]*>' /tmp/body.html | head -2

perl -0777 -ne 'while(/<a\b([^>]*href=["\x27](https?:\/\/[^"\x27]+)["\x27][^>]*)>/gi){
  $attr=$1; $href=$2;
  $rel = ($attr=~/rel=["\x27]([^"\x27]*)["\x27]/i) ? $1 : "NO-REL(dofollow)";
  print "$rel\t$href\n";
}' /tmp/body.html | sort -u

Run it against a competitor's listing, not your own — you want to see what the platform actually publishes, not what it promises.

Failure mode 1: the page is dofollow and noindex

The link is followed. The page it lives on is not in the index. Nothing flows.

Two of the most-recommended "free dofollow" platforms do this to free accounts specifically:

A popular hosted-changelog product gives you a public changelog page with genuinely followed links. The free plan force-noindexes that page. Indexing is a paid upgrade.
A large GIF platform's brand channels render the website field as rel="noopener noreferrer" — followed. User channels stay noindex until the brand is verified.

Both were on every list I read. Neither list mentioned the robots meta. rel on a noindex page is worth nothing, and no rel checker will tell you that, because it isn't looking at the head.

Failure mode 2: the canonical points somewhere else

This one is nastier because the page passes both obvious checks.

One well-known developer-tools directory serves robots: index, follow on its tool pages, and the vendor link is rel="noopener noreferrer" — followed. Perfect, on the surface.

Every single tool page also serves:

<link rel="canonical" href="https://thatdirectory.example/"/>

Homepage. Site-wide. Your page tells Google "I am the homepage." A canonical is a strong hint, and while Google can reject it, you are betting your link on that rejection. I could not prove those pages get indexed independently, and I'm not going to claim they do.

Check the canonical. It takes one grep.

Failure mode 3: the dofollow you measured was a paid listing

This is the one that got me, and it's the reason I'm writing this.

I measured three launch platforms with the script. All three: followed vendor links, indexable pages. I wrote them up as "do this."

Then I actually submitted to one. The confirmation email listed "do-follow backlinks" as a benefit of the $49 tier.

Go back and look at the others with that in mind and the pattern is obvious:

One directory's product links are rel="nofollow noopener noreferrer", while the sponsor slots on the very same page are rel="noopener" — followed. Same HTML, same template, two different link policies, sorted by who paid.
Another platform's free tier requires a reciprocal badge on your own site. Not one of the five followed listings I sampled had that badge anywhere on their site — meaning those five almost certainly weren't free listings at all.

So there's a fourth gate, and it's the one nobody checks:

rel · robots · canonical · and which pricing tier was the page you measured published under?

A live page's rel is evidence about that listing. It is not evidence about yours. You often cannot know until your own page goes live — which means the honest answer for a queued free submission is "unproven," not "dofollow."

Failure mode 4: there is no link at all

Worth checking before you spend an hour on a submission form:

A large software-comparison site: index, follow, self-canonical, dedicated category pages, comparison pages — and zero outbound anchors to the vendor. The whole page is about the product and never links to it.
A startup directory whose homepage is full of followed outbound links (they're sponsor slots) while the permanent detail page for each listing links nowhere.
An integrations marketplace with a page per app and no link to the app's own site.

And two that block it at a completely different layer:

A PR-source platform's expert directory looked like a free profile with a website field. Its robots.txt:

  User-agent: *
  Disallow: /profile/

Every profile URL is also signed with a token and redirects to the login page without one.

The WordPress.org plugin directory. Everyone "knows" it's a high-authority free dofollow. Every vendor link on a plugin page is rel="nofollow ugc". Writing a plugin can be great distribution. It is not a link.

The scoreboard

Twenty platforms where I could measure what a free account actually gets:

Outcome	Count
Followed and indexable and actually free	1
Followed but `noindex` on the free plan	2
Followed but canonicalized away	1
Followed only on paid listings (or unproven for free)	3
`nofollow`	5
No outbound link at all	5
Blocked by `robots.txt` / no crawlable page	3

The one that passed everything was a plain software directory with a normal listing, no upsell attached to the link, and no reciprocal-badge condition. It is also, per Bing Webmaster Tools, the only legitimate referring domain my site has.

A mistake I made, so you don't

Seven platforms returned 403 or 429 to curl. Their block pages helpfully serve:

<meta name="robots" content="noindex, nofollow">

I nearly recorded that as the verdict. That's the block page's meta, not the real page's. I wrote one platform off as dead on a 429 — then opened it in a logged-in browser and found a live product with 606 open queries in it.

If a bot wall stops you, the honest status is "unmeasured." Open it in a real browser or leave the row blank.

What I'd actually do instead

The pattern across all twenty is consistent enough to be a rule: modern directories nofollow the free listing and sell the dofollow. That isn't a conspiracy, it's a business model, and it means grinding a list of 100 directories is a way to spend fifty hours building the exact footprint you'll later disavow.

For context on why that matters to me: my domain has ~103 referring domains and 104 entries on its disavow file. The list-driven approach is how you get there.

What's left, once you take the directories out, is unglamorous: write things worth citing, answer questions where you genuinely have first-hand data, and get covered by publications your audience actually reads. Editorial links carry no rel at all — I checked a national tech publication's articles while writing this, and every outbound link in the body was bare.

Slower. But there's no tier that takes it away from you.

I'm building Linkhiver, a link-in-bio tool localized in seven languages. The measurements above come from doing this badly for my own domain first.

Your Computer Is Busy When You're Not: Building a Desktop Observability Tool with Electron

Nishikanta Ray — Sun, 23 Aug 2026 17:14:54 +0000

You close your laptop.

The screen goes dark.

You assume everything stopped.

But what if it didn't?

Maybe Docker is still transferring data.

Maybe Chrome is still downloading something.

Maybe an application is consuming CPU in the background.

Maybe your computer woke up at 3 AM, performed some background work, and went back to sleep.

Most operating systems already expose pieces of this information.

The interesting part is putting those pieces together.

That's what I wanted to explore:

Can we build an observability layer for a desktop computer using Electron?

Not another CPU/RAM widget.

Something that answers:

What is my computer actually doing?

The Idea

Imagine opening your desktop monitoring application and seeing:

TODAY
────────────────────────────────────

Computer active        7h 42m
Idle                   1h 13m
Sleep                  8h 05m

Network
↓ Download             6.8 GB
↑ Upload               1.2 GB

Top applications
────────────────────────────────────

VS Code                3h 42m
Chrome                 2h 18m
Docker                 1h 31m
Slack                  52m

Network-heavy apps
────────────────────────────────────

Docker                 2.4 GB
Chrome                 1.8 GB
VS Code                920 MB

Now imagine clicking "What happened while I was away?"

18:42  User became idle
18:51  Screen locked
18:53  Docker network activity
19:07  Background sync completed
19:14  System entered sleep

That's much more interesting than a CPU percentage.

The npm Package That Makes This Easier

Instead of writing native system integrations for everything ourselves, we can start with:

npm install systeminformation

systeminformation provides APIs for system information, CPU, memory, battery, filesystem, network, processes, Docker and more. It also supports Linux, macOS and Windows, although individual APIs have platform-specific support.

For example:

const si = require("systeminformation");

async function getSystemStats() {
  const [cpu, memory, battery, network] = await Promise.all([
    si.currentLoad(),
    si.mem(),
    si.battery(),
    si.networkStats()
  ]);

  return {
    cpu: cpu.currentLoad,
    memory: memory.active,
    battery: battery.percent,
    network
  };
}

console.log(await getSystemStats());

Now our Electron main process can periodically collect system information.

Monitoring Network Activity

One of the most useful APIs is:

si.networkStats()

It provides network statistics including received/transmitted bytes and calculated per-second rates. The package calculates rates based on differences between successive calls, so the first call doesn't provide a meaningful rate yet.

A simple monitor:

const si = require("systeminformation");

setInterval(async () => {
  const stats = await si.networkStats();

  for (const network of stats) {
    console.log({
      interface: network.iface,
      download: network.rx_sec,
      upload: network.tx_sec
    });
  }
}, 1000);

Now we have something like:

Wi-Fi
Download: 2.4 MB/s
Upload:   180 KB/s

But this is only the beginning.

Network Connections

We can also inspect active network connections:

const connections = await si.networkConnections();

console.log(connections);

This gives us information about active TCP/UDP connections.

That means we can potentially build:

Active Connections
────────────────────────────

TCP    443    api.example.com
TCP    443    github.com
TCP    443    google.com
UDP    53     DNS

Now the dashboard starts becoming useful for troubleshooting.

Which Application Is Active?

Network traffic alone doesn't tell us who is responsible.

We also want to know which application the user is interacting with.

One option is a native active-window module such as:

npm install @jannchie/active-window

The package exposes information about the currently selected window and user idle time on supported Windows, macOS and Linux/Xorg environments. Platform coverage isn't identical everywhere, so this should be treated as an OS-dependent component.

Conceptually:

const activeWindow = require("@jannchie/active-window");

async function getActiveApp() {
  const window = await activeWindow().getActiveWindow();

  return {
    process: window.windowClass,
    title: window.windowName
  };
}

Then we can record:

10:32:14  VS Code
10:32:15  VS Code
10:32:16  VS Code
...
10:45:02  Chrome
10:45:03  Chrome

Instead of storing every second individually, we can aggregate this into sessions.

VS Code
10:32 → 10:45
Duration: 13 minutes

Sleep and Wake

This is where Electron itself becomes useful.

Electron provides the powerMonitor module for monitoring system power-state changes, including suspend/resume, AC/battery changes, idle state and lock/unlock events on supported platforms.

In the Electron main process:

const { powerMonitor } = require("electron");

powerMonitor.on("suspend", () => {
  console.log("System is going to sleep");
});

powerMonitor.on("resume", () => {
  console.log("System woke up");
});

We can turn those events into database records:

function recordEvent(type) {
  db.insert({
    type,
    timestamp: new Date()
  });
}

powerMonitor.on("suspend", () => {
  recordEvent("system_sleep");
});

powerMonitor.on("resume", () => {
  recordEvent("system_wake");
});

Now our timeline knows when the machine slept.

Idle Detection

Electron also provides:

powerMonitor.getSystemIdleTime()

and:

powerMonitor.getSystemIdleState(60)

The latter can return states such as active, idle, or locked on supported systems.

For example:

const state = powerMonitor.getSystemIdleState(60);
const idleSeconds = powerMonitor.getSystemIdleTime();

console.log({
  state,
  idleSeconds
});

We can therefore distinguish:

Active
   ↓
Idle
   ↓
Locked
   ↓
Sleep

That's much more meaningful than simply measuring application runtime.

Putting Everything Together

Now imagine collecting events from four sources:

                 Electron App
                      │
       ┌──────────────┼──────────────┐
       │              │              │
  powerMonitor   systeminformation   active-window
       │              │              │
       │         CPU / RAM / Net     Active App
       │              │              │
       └──────────────┼──────────────┘
                      ▼
                Event Collector
                      │
                      ▼
                Local Database
                      │
                      ▼
              Activity Timeline

A simple event model could be:

{
  timestamp: Date.now(),
  type: "network",
  app: "docker",
  downloadBytes: 1824000,
  uploadBytes: 420000
}

Or:

{
  timestamp: Date.now(),
  type: "power",
  state: "sleep"
}

Or:

{
  timestamp: Date.now(),
  type: "application",
  app: "Code",
  window: "server.js - Visual Studio Code"
}

Now everything becomes queryable.

The Interesting Part: Correlation

This is where a normal system monitor becomes a desktop observability tool.

Suppose we see:

18:20  User idle
18:23  CPU 65%
18:24  Network 18 MB/s
18:26  Docker active
18:31  420 MB downloaded
18:42  Screen locked
18:45  Network still active
19:02  System sleep

We can generate an explanation:

Docker continued running after the user became idle and transferred approximately 420 MB before the system entered sleep.

That's an insight.

Not just a metric.

A Simple Collector

We could start with something surprisingly small:

const { powerMonitor } = require("electron");
const si = require("systeminformation");

async function collect() {
  const [cpu, memory, network] = await Promise.all([
    si.currentLoad(),
    si.mem(),
    si.networkStats()
  ]);

  return {
    timestamp: Date.now(),

    system: {
      idle: powerMonitor.getSystemIdleTime(),
      idleState: powerMonitor.getSystemIdleState(60),
      battery: powerMonitor.isOnBatteryPower()
    },

    cpu: cpu.currentLoad,

    memory: {
      active: memory.active,
      total: memory.total
    },

    network: network.map(n => ({
      interface: n.iface,
      rxPerSecond: n.rx_sec,
      txPerSecond: n.tx_sec
    }))
  };
}

setInterval(async () => {
  console.log(await collect());
}, 5000);

Five seconds later, we have the beginning of our own desktop telemetry system.

But Don't Collect Everything Every Second

This is an important design decision.

You don't necessarily want:

Every 1 second
    ↓
Everything
    ↓
Database

That can generate enormous amounts of useless data.

Instead, use different collection intervals.

Power events        Event-driven
App changes         Event-driven
CPU                 5-10 seconds
Memory              10 seconds
Network             1-5 seconds
Connections         10-30 seconds
Daily aggregates    1 minute+

And store state changes rather than repeated identical states.

For example, don't write:

10:00 VS Code
10:01 VS Code
10:02 VS Code
10:03 VS Code
10:04 VS Code

Store:

VS Code
10:00 → 10:04
Duration: 4 minutes

This makes the database dramatically smaller.

What About Electron's Network Logging?

If the thing you're monitoring is specifically your Electron application's own network traffic, Electron has another useful tool: netLog.

const { app, netLog } = require("electron");

app.whenReady().then(async () => {
  await netLog.startLogging("/tmp/electron-network-log");
});

Electron's netLog records network events for a session and supports different capture modes. Be careful with includeSensitive and everything, because those modes can capture sensitive information or transferred bytes.

This is different from systeminformation:

systeminformation
        ↓
Whole-system information

Electron netLog
        ↓
Your Electron application's network activity

That distinction is important.

The Product I Would Build

I wouldn't call this another "Task Manager."

I'd call it something like:

Desktop Observability

The dashboard could have four major views.

1. Activity

VS Code       4h 12m
Chrome        2h 31m
Slack         58m
Docker        1h 42m

2. Network

Download     8.4 GB
Upload       1.3 GB

Docker       3.1 GB
Chrome       2.7 GB
VS Code      1.2 GB

3. Power

Active       8h 21m
Idle         1h 08m
Sleep        7h 42m

Battery used 34%

4. Timeline

09:02  Wake
09:05  VS Code
10:32  Chrome
12:14  Idle
12:31  Docker network activity
13:02  Active
18:42  Lock
19:01  Sleep

And then the killer feature:

Ask the computer

Why was my laptop slow today?

What used the most bandwidth?

What happened while I was away?

Which applications are active in the background?

Did anything continue running after I locked the computer?

The Architecture

A practical first version could be:

Electron
│
├── Main Process
│   │
│   ├── powerMonitor
│   ├── systeminformation
│   ├── active-window
│   └── netLog
│
├── Collector
│   │
│   ├── power events
│   ├── app sessions
│   ├── CPU/memory
│   └── network stats
│
├── SQLite
│
└── React Renderer
    │
    ├── Dashboard
    ├── Timeline
    ├── Applications
    ├── Network
    └── Power

The key design principle is:

Collect locally. Correlate locally. Explain locally.

You don't need to send a user's entire computer activity to a cloud server just to tell them why their laptop was busy.

The Bigger Idea

The interesting thing here isn't systeminformation.

It isn't Electron's powerMonitor.

It isn't network monitoring.

It's the combination.

A computer is already generating thousands of signals:

Applications
Processes
CPU
Memory
Network
Power
Sleep
Wake
Idle
Lock
Unlock

Today, these signals are mostly presented independently.

A desktop observability layer could connect them.

And instead of asking:

"What's my CPU usage?"

we can finally ask:

"What happened on my computer while I wasn't looking?"

That's a much more interesting monitoring problem.

The Coverage Loop: Turning Free AI Tokens into Verified C++ Tests

Morgan Ma — Sun, 23 Aug 2026 17:11:55 +0000

Unit tests are boring. Coverage is not optional.
I asked a free AI model to write my tests. It failed. Then I built a feedback loop.
Here is the result: a reproducible pipeline that turns free tokens into measured coverage.

Why Generated Tests Miss Everything

Models guess. They do not know your intent.
A test that compiles is not a test that asserts. A test that asserts is not a test that covers.
The fix is not a better prompt. The fix is a measurement loop.

The Experiment

MonkeyCode is an open-source AI coding tool. It offers free model access and a free server option.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
I used its free tier for this experiment. At the time of writing, it includes a 10M token allowance and a free server.

The target: a small C++ string utility.
The goal: reach 90% line coverage with generated tests.

The Loop

Five steps. Each one is small.

Send the header to the model. Ask for tests.
Compile and run the tests.
Run gcov. Get the coverage number.
Feed the missing lines back to the model.
Repeat until coverage plateaus.

Here is the core script. It is simplified but runnable.

#!/usr/bin/env python3
"""coverage_loop.py - generate C++ tests, measure coverage, iterate."""

import subprocess
import requests

BASE_URL = 'https://your-provider/v1'
API_KEY = 'your-key'
MODEL = 'free-model'

def generate_tests(header: str, hint: str = '') -> str:
    prompt = f'Write a C++ test file for this header:{chr(10)}{header}{chr(10)}'
    if hint:
        prompt += f'{chr(10)}Current tests miss these lines: {hint}{chr(10)}Add tests to cover them.'
    resp = requests.post(f'{BASE_URL}/chat/completions',
                         headers={'Authorization': f'Bearer {API_KEY}'},
                         json={'model': MODEL, 'messages': [{'role': 'user', 'content': prompt}], 'temperature': 0.2})
    return resp.json()['choices'][0]['message']['content']

def run_tests() -> float:
    subprocess.run(['g++', '-std=c++17', '--coverage', '-o', 'tests',
                    'string_utils.cpp', 'test_string_utils.cpp'], check=True)
    subprocess.run(['./tests'], check=True)
    out = subprocess.run(['gcov', '-b', 'string_utils.cpp'], capture_output=True, text=True).stdout
    for line in out.splitlines():
        if 'Lines executed' in line:
            return float(line.split(':')[1].strip().split('%')[0])
    return 0.0

def missing_lines() -> str:
    return '12-15, 28-30'

def main():
    header = open('string_utils.h').read()
    for i in range(5):
        hint = '' if i == 0 else f'lines {missing_lines()}'
        test_code = generate_tests(header, hint)
        open('test_string_utils.cpp', 'w').write(test_code)
        try:
            coverage = run_tests()
        except subprocess.CalledProcessError:
            print('compilation failed, retrying')
            continue
        print(f'iteration {i+1}: {coverage}%')
        if coverage >= 90:
            break

if __name__ == '__main__':
    main()

Set BASE_URL, API_KEY, and MODEL to your provider's values. Drop your header and source in the same directory. Run it.

python coverage_loop.py

Example Run

One run produced this pattern. Your numbers will differ.

Iteration	Coverage	What changed
1	42%	Tests compiled, missed edge cases
2	71%	Added empty-string tests
3	88%	Added null-byte handling
4	91%	Plateau, stopped

The loop works. The model found obvious edge cases. Empty strings. Negative numbers.
It missed stateful behavior. Two calls in sequence. That is where gcov saved me.

Where the Loop Breaks

Free servers rate-limit. I added retry logic. It still stuttered.
The model generated uncompilable tests. I skipped them. That wastes tokens.
Coverage is not correctness. A test can cover a line and assert nothing.

Who Should Skip This

Safety-critical code. Do not trust generated tests.
Legacy code with hidden dependencies. The model will guess wrong.
Teams without a CI runner. The loop needs automation.

The Takeaway

Free AI is not a test engineer. It is a test generator with a feedback loop.
The loop turns tokens into coverage. Coverage tells you where to spend the next token.
That is the real trick. Not more prompts. Better signals.
Fork the script. Run it on your worst file. Tell me what breaks.